home *** CD-ROM | disk | FTP | other *** search
- # The IKE Scanner (ike-scan) is Copyright (C) 2003-2005 Roy Hills,
- # NTA Monitor Ltd.
- #
- # This program is free software; you can redistribute it and/or
- # modify it under the terms of the GNU General Public License
- # as published by the Free Software Foundation; either version 2
- # of the License, or (at your option) any later version.
- #
- # This program is distributed in the hope that it will be useful,
- # but WITHOUT ANY WARRANTY; without even the implied warranty of
- # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- # GNU General Public License for more details.
- #
- # You should have received a copy of the GNU General Public License
- # along with this program; if not, write to the Free Software
- # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- #
- # If this license is unacceptable to you, I may be willing to negotiate
- # alternative licenses (contact ike-scan@nta-monitor.com).
- #
- # $Id: ike-vendor-ids,v 1.33 2005/10/26 10:47:54 rsh Exp $
- #
- # ike-vendor-ids -- File containing known Vendor IDs for ike-scan
- #
- # Author: Roy Hills <Roy.Hills@nta-monitor.com>
- #
- # Format:
- # Implementation_Name<Tab>Vendor_ID_Pattern
- #
- # The Vendor_ID_Pattern should be specified as a Posix extended regular
- # expression that will match the hex value of the Vendor ID. The Posix regular
- # expression routines "regcomp" and "regexec" are used to compile and
- # match the patterns.
- #
- # The hex value of the Vendor ID can only contain the characters [0-9a-f].
- # The regular expression match is case insensitive so you can use either
- # upper or lower case letters [A-F] in the pattern, although I recommend that
- # you use only lower-case for consistency.
- #
- # The pattern is not anchored by default. If you want to match from the
- # beginning of the vendor ID hex value (which is normally the case), you
- # should start your pattern with "^" to anchor it at the beginning of the hex
- # value. If you don't want to allow any extra trailing data, you should end
- # the pattern with "$" to anchor it at the end of the hex value.
- #
- # Each entry must be on one line. A line can be up to 254 characters long.
- # To allow for longer lines, adjust the MAXLINE macro in ike-scan.h
- #
- # Lines beginning with '#' and blank lines are ignored.
- #
- # The input format is quite strict. In particular, the separator between
- # the implementation name and the VendorID pattern must be a single TAB and
- # not a space.
- #
- # If you have problems adding entries, run ike-scan as:
- # ike-scan -v -v -v <any-target>
- # Which will dump the VendorID pattern table.
- #
- # You are encouraged to send comments, improvements or suggestions to
- # me at ike-scan@nta-monitor.com.
- #
-
- # Microsoft/Cisco IPsec implementation for Win-2000 and above.
- # The first 16 bytes are the MD5 hash of "MS NT5 ISAKMPOAKLEY"
- # I've seen extra data following the XP-SP1 and 2003 patterns, but I'm not sure
- # what this represents.
- Windows-2000 ^1e2b516905991c7d7c96fcbfb587e46100000002
- Windows-XP-SP1 ^1e2b516905991c7d7c96fcbfb587e46100000003
- Windows-2003-or-XP-SP2 ^1e2b516905991c7d7c96fcbfb587e46100000004
-
- # Checkpoint Firewall-1/VPN-1
- #
- # Firewall-1 v4.0 didn't use Vendor IDs. v3.0 and below didn't support IPsec.
- #
- # This is a 40-byte Vendor ID, which consists of the following fields:
- #
- # Bytes Description
- # 1-20 Checkpoint VID (Probably an SHA1 hash of something)
- # 21-24 Product (1=Firewall-1, 2=SecuRemote/SecureClient)
- # 25-28 Encoded Version number
- # 29-32 Timestamp (NGX only; always zero in 4.1 or NG)
- # 33-36 Reserved
- # 37-40 Features
- #
- # The Checkpoint VID is "f4ed19e0c114eb516faaac0ee37daf2807b4381f". This
- # looks like an SHA1 hash.
- #
- # The Product is either 1 (0x00000001) for Firewall-1/VPN-1 or 2 (0x00000002)
- # for SecuRemote/SecureClient (Checkpoint's VPN client).
- #
- # The encoded version number is described in the URL below.
- #
- # The timestamp field contains the Firewall's date and time encoded as seconds
- # since 1st Jan 1970 (standard Unix epoch). Only NGX fills this in; it is
- # always zero on 4.1 and NG.
- #
- # The first byte of the features field contains the number of bits used. This
- # is normally 0x18 (24). The remaining three bytes (24 bits) are feature
- # flags.
- #
- # Firewall-1 4.1 and NG only returns a Vendor ID if you send a Vendor ID
- # payload starting with the Checkpoint VID. Firewall-1 NGX always returns
- # a Vendor ID, regardless of whether the client sends the Checkpoint VID
- # or not.
- #
- # See http://www.nta-monitor.com/news/checkpoint2004/index.htm for full details
- #
- Firewall-1 4.1 Base ^f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000020000000000000000........
- Firewall-1 4.1 SP1 ^f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000030000000000000000........
- Firewall-1 4.1 SP2-SP6 ^f4ed19e0c114eb516faaac0ee37daf2807b4381f0000000100000fa20000000000000000........
- Firewall-1 NG Base ^f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000013880000000000000000........
- Firewall-1 NG FP1 ^f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000013890000000000000000........
- Firewall-1 NG FP2 ^f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138a0000000000000000........
- Firewall-1 NG FP3 ^f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138b0000000000000000........
- Firewall-1 NG AI R54 ^f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c0000000000000000........
- Firewall-1 NG AI R55 ^f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d0000000000000000........
- Firewall-1 NGX ^f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d........00000000........
- Firewall-1 Unknown Vsn ^f4ed19e0c114eb516faaac0ee37daf2807b4381f
-
- # Dead Peer Detection (DPD), detailed in RFC 3706.
- # Last 2 bytes (4 hex chars) are major & minor version.
- # Current version is 1.0.
- # Thanks to Hakan Olsson for clarifing this.
- Dead Peer Detection ^afcad71368a1f1c96b8696fc7757....
-
- # XAUTH
- # This is a truncated MD5 hash of "draft-ietf-ipsra-isakmp-xauth-06.txt"
- # Why "ipsra" and not "ipsec" as in the draft name I wonder?
- XAUTH ^09002689dfd6b712
-
- # SSH Communications Security IPSEC Express
- # These VIDs are MD5 hashes of the text
- # "SSH Communications Security IPSEC Express version x.y.z" or
- # "Ssh Communications Security IPSEC Express version x.y.z"
- # Where x.y.z is the version, e.g. 1.1.0
- SSH IPSEC Express 1.1.0 ^fbf47614984031fa8e3bb6198089b223
- SSH IPSEC Express 1.1.1 ^1952dc91ac20f646fb01cf42a33aee30
- SSH IPSEC Express 1.1.2 ^e8bffa643e5c8f2cd10fda7370b6ebe5
- SSH IPSEC Express 1.2.1 ^c1111b2dee8cbc3d620573ec57aab9cb
- SSH IPSEC Express 1.2.2 ^09ec27bfbc09c75823cfecbffe565a2e
- SSH IPSEC Express 2.0.0 ^7f21a596e4e318f0b2f4944c2384cb84
- SSH IPSEC Express 2.1.0 ^2836d1fd2807bc9e5ae30786320451ec
- SSH IPSEC Express 2.1.1 ^a68de756a9c5229bae66498040951ad5
- SSH IPSEC Express 2.1.2 ^3f2372867e237c1cd8250a75559cae20
- SSH IPSEC Express 3.0.0 ^0e58d5774df602007d0b02443660f7eb
- SSH IPSEC Express 3.0.1 ^f5ce31ebc210f44350cf71265b57380f
- SSH IPSEC Express 4.0.0 ^f64260af2e2742daddd56987068a99a0
- SSH IPSEC Express 4.0.1 ^7a54d3bdb3b1e6d923892064be2d981c
- SSH IPSEC Express 4.1.0 ^9aa1f3b43472a45d5f506aeb260cf214
- SSH IPSEC Express 4.1.1 ^89f7b760d86b012acf263382394d962f
- SSH IPSEC Express 4.2.0 ^6880c7d026099114e486c55430e7abee
- SSH IPSEC Express 5.0 ^b037a21aceccb5570f602546f97bde8c
- SSH IPSEC Express 5.0.0 ^2b2dad97c4d140930053287f996850b0
- SSH IPSEC Express 5.1.0 ^45e17f3abe93944cb202910c59ef806b
- SSH IPSEC Express 5.1.1 ^5925859f7377ed7816d2fb81c01fa551
-
- # Cisco Unity compliant peer. VID is the MD5 hash of "CISCO-UNITY" with
- # the last two bytes replaced with 0x0100
- Cisco Unity ^12f5f28c457168a9702d9fe274cc0100
-
- # I've seen this pattern with trailing 500306 and 500400. I suspect that
- # the last two bytes indicate the version number, e.g 0306 = 3.0.6. However,
- # I need more examples before I'm confident that this is the case, so for
- # now I'm just including the generic pattern.
- Cisco VPN Concentrator ^1f07f70eaa6514d3b0fa96542a
-
- # IKE Fragmentation. VID is the MD5 hash of the text "FRAGMENTATION"
- # I've seen extra bytes on the end of a fragmentation VID payload, e.g.
- # c0000000. I don't know what these represent.
- IKE Fragmentation ^4048b7d56ebce88525e7de7f00d6c2d3
-
- # Various IKE Internet drafts. The VID payload is the MD5 hash of the
- # implementation name given below.
- draft-stenberg-ipsec-nat-traversal-01 ^27bab5dc01ea0760ea4e3190ac27c0d0
- draft-stenberg-ipsec-nat-traversal-02 ^6105c422e76847e43f9684801292aecd
- draft-huttunen-ipsec-esp-in-udp-00.txt ^6a7434c19d7e36348090a02334c9c805
-
- # Extra data has been observed at the end of this VID payload.
- SafeNet SoftRemote ^47bbe7c993f1fc13b4e6d0db565c68e5
-
- # HeartBeat Notify.
- # VID is ASCII "HeartBeat_Notify"
- # Extra data has been observed at the end of this VID payload. It is
- # suspected that this may be a version number. E.g:
- # 4865617274426561745f4e6f74696679386b0100
- Heartbeat Notify ^4865617274426561745f4e6f74696679
-
- OpenPGP ^4f70656e5047503130313731
-
- # draft-huttunen-ipsec-esp-in-udp-01.txt
- # VID is an MD5 hash of "ESPThruNAT"
- ESPThruNAT ^50760f624c63e5c53eea386c685ca083
-
- # SSH Sentinel.
- # These VIDs are MD5 hashes of the implementation names given below.
- SSH Sentinel ^054182a07c7ae206f9d2cf9d2432c482
- SSH Sentinel 1.1 ^b91623e693ca18a54c6a2778552305e8
- SSH Sentinel 1.2 ^5430888de01a31a6fa8f60224e449958
- SSH Sentinel 1.3 ^7ee5cb85f71ce259c94a5c731ee4e752
- SSH Sentinel 1.4 ^63d9a1a7009491b5a0a6fdeb2a8284f0
- SSH Sentinel 1.4.1 ^eb4b0d96276b4e220ad16221a7b2a5e6
-
- # Timestep VID is ASCII "TIMESTEP" (54494d4553544550) followed by further
- # ASCII characters which seem to indicate a version number. e.g:
- # 54494d455354455020312053475720313532302033313520322e303145303133
- # which is "TIMESTEP 1 SGW 1520 315 2.01E013"
- Timestep ^54494d4553544550
-
- # VID is MD5 hash of "KAME/racoon"
- KAME/racoon ^7003cbc1097dbe9c2600ba6983bc8b35
-
- # Negotiation of NAT-Traversal in the IKE - previously IETF draft, now RFC.
- # The VID is the MD5 hash of the implementation name given below.
- # The trailing newline (\n) on one entry is explained in
- # http://www.sandelman.ottawa.on.ca/ipsec/2002/04/msg00233.html
- # Jan 2005: RFC released as RFC 3947 "Negotiation of NAT-Traversal in the IKE"
- # VID is MD5 hash of "RFC 3947"
- draft-ietf-ipsec-nat-t-ike ^4df37928e9fc4fd1b3262170d515c662
- draft-ietf-ipsec-nat-t-ike-00 ^4485152d18b6bbcd0be8a8469579ddcc
- draft-ietf-ipsec-nat-t-ike-01 ^16f6ca16e4a4066d83821a0f0aeaa862
- draft-ietf-ipsec-nat-t-ike-02\n ^90cb80913ebb696e086381b5ec427b1f
- draft-ietf-ipsec-nat-t-ike-02 ^cd60464335df21f87cfdb2fc68b6a448
- draft-ietf-ipsec-nat-t-ike-03 ^7d9419a65310ca6f2c179d9215529d56
- draft-ietf-ipsec-nat-t-ike-04 ^9909b64eed937c6573de52ace952fa6b
- draft-ietf-ipsec-nat-t-ike-05 ^80d0bb3def54565ee84645d4c85ce3ee
- draft-ietf-ipsec-nat-t-ike-06 ^4d1e0e136deafa34c4f3ea9f02ec7285
- draft-ietf-ipsec-nat-t-ike-07 ^439b59f8ba676c4c7737ae22eab8f582
- draft-ietf-ipsec-nat-t-ike-08 ^8f8d83826d246b6fc7a8a6a428c11de8
- draft-ietf-ipsec-nat-t-ike-09 ^42ea5b6f898d9773a575df26e7dd19e1
- Testing NAT-T RFC ^c40fee00d5d39ddb1fc762e09b7cfea7
- RFC 3947 NAT-T ^4a131c81070358455c5728f20e95452f
-
- # A GSS-API Authentication Method for IKE - draft-ietf-ipsec-isakmp-gss-auth
- # This is used by Windows 2000 and later. Specific Windows VIDs are in a
- # separate section.
- # Note that the MD5 hash for "A GSS-API ..." in draft version 07 is given as
- # the hash of the string with a newline appended. I think that this is an
- # error, so I've added patterns both with and without the trailing newline.
- MS NT5 ISAKMPOAKLEY ^1e2b516905991c7d7c96fcbfb587e461
- A GSS-API Authentication Method for IKE ^ad2c0dd0b9c32083ccba25b8861ec455
- A GSS-API Authentication Method for IKE\n ^b46d8914f3aaa3f2fedeb7c7db2943ca
- GSSAPI ^621b04bb09882ac1e15935fefa24aeee
-
- # Nortel Contivity VPN Router (was Bay Networks Enterprise Switch)
- # The first 4 bytes are ASCII "BNES" (Bay Networks Enterprise Switch)
- # The second 4 bytes appear to be a version number in big endian format.
- # I've seen values 00000004, 00000005, 00000007, 00000009 and 0000000a in
- # this position.
- Nortel Contivity ^424e4553000000..
-
- # Observed to be sent from SonicWall Firewalls
- SonicWall ^404bf439522ca3f6
-
- # SSH QuickSec
- # The VIDs are the MD5 hashes of "SSH Communications Security QuickSec x.y.z"
- # Where x.y.z is the version number
- SSH QuickSec 0.9.0 ^37eba0c4136184e7daf8562a77060b4a
- SSH QuickSec 1.1.0 ^5d72925e55948a9661a7fc48fdec7ff9
- SSH QuickSec 1.1.1 ^777fbf4c5af6d1cdd4b895a05bf82594
- SSH QuickSec 1.1.2 ^2cdf08e712ede8a5978761267cd19b91
- SSH QuickSec 1.1.3 ^59e454a8c2cf02a34959121f1890bc87
-
- # VIDs are MD5 hash of:
- # "IKE Challenge/Response for Authenticated Cryptographic Keys"
- # "IKE Challenge/Response for Authenticated Cryptographic Keys (Revised)"
- # both without and with trailing newline.
- IKE Challenge-Response ^ba290499c24e84e53a1d83a05e5f00c9
- IKE Challenge-Response-2 ^0d33611a5d521b5e3c9c03d2fc107e12
- IKE Challenge-Response Revised ^ad3251042cdc4652c9e0734ce5de4c7d
- IKE Challenge-Response Revised-2 ^13f11823f966fa91900f024ba66a86ba
-
- # draft-krywaniuk-ipsec-antireplay-00.txt - Using Isakmp Message Ids for
- # Replay Protection
- #
- # "They may also be enabled in the short term by mutual exchange of the
- # vendor id 0x325df29a2319f2dd"
- draft-krywaniuk-ipsec-antireplay-00 ^325df29a2319f2dd
-
- # draft-ietf-ipsec-heartbeats-00.txt - Using Isakmp Heartbeats for Dead Peer
- # Detection
- # The draft says that the VID is a truncated MD5 hash of
- # "draft-ietf-krywaniuk-ipsec-heartbeats-00.txt"
- # but it is not.
- draft-ietf-ipsec-heartbeats-00 ^8db7a41811221660
-
- # MacOS X
- # Unconfirmed, from StrongSwan vendor.c
- MacOS 10.x ^4d6163204f53582031302e78
-
- # StrongSwan
- # VID is MD5 hash of "strongSwan x.y.z" where x.y.z is version number
- # Obtained from StrongSwan vendor.c
- StrongSwan 2.2.0 ^86f9f547c5d3ba6720dce9ccd17ac0c2
- StrongSwan 2.2.1 ^8dfbb1ebec630f0efe557a7f3e13cd36
- StrongSwan 2.2.2 ^8a6903daeb705b35d2eac3fb1a62551c
- StrongSwan 2.3.0 ^bb14bc5527a2a8289eeb25149d5f661b
- StrongSwan 2.3.1 ^6b75fd64516a6cb6441fedd0c6b4e2b1
- StrongSwan 2.3.2 ^56546e1ff761fcb1cc7fb0f1fee978ea
- StrongSwan 2.4.0 ^20f0af7152332de372e9394138e0253a
- StrongSwan 2.4.1 ^486b3d5c7365a47a10df811660e5894e
-
- # ZyXEL ZyWALL router
- # Observed on several devices. HTTP interface shows that they are XyWALL
- # I suspect that this VID is an SHA-1 hash of something because of the length
- XyXEL ZyWALL Router ^b858d1addd08c1e8adafea150608aa4497aa6cc8
-
- # Microsoft Initial Contact
- # VID is MD5 hash of "Vid-Initial-Contact"
- Microsoft Initial-Contact ^26244d38eddb61b3172a36e3d0cfb819
-
- # FreeS/WAN and Openswan
- # VID is a 12-byte printable string. The first two bytes are "OE", which
- # stands for "Opportunistic Encryption" (the FreeS/WAN designers were
- # enthusiastic about opportunistic encryption); the remaining ten bytes are
- # a truncated, "ASCIIfied" MD5 hash of the implementation name given below.
- # The "ASCIIfication" process involves clearing bit 7 and setting bit 6 in
- # each byte, thus constraining the range to 64-127 inclusive.
- # I think that support for this VID was added in FreeS/WAN 2.00, and carried
- # over into openswan 2.x.
- Linux FreeS/WAN 2.00 ^4f45486b7d44784d42676b5d
- Linux FreeS/WAN 2.01 ^4f457c4f547e6e615b426e56
- Linux FreeS/WAN 2.02 ^4f456c6b44696d7f6b4c4e60
- Linux FreeS/WAN 2.03 ^4f45566671474962734e6264
- Linux FreeS/WAN 2.04 ^4f45704f736579505c6e5f6d
- Linux FreeS/WAN 2.05 ^4f457271785f4c7e496f4d54
- Linux FreeS/WAN 2.06 ^4f457e4c466e5d427c5c6b52
- Openswan 2.2.0 ^4f4548724b6e5e68557c604f
- Openswan 2.3.0 ^4f4572696f5c77557f746249
-
- # OpenPGP
- # VID starts with ASCII "OpenPGP". This is generally followed by some extra
- # data, e.g. "OpenPGP10171", but we don't match that.
- OpenPGP ^4f70656e504750
-
- # Observed on Fortinet ForteGate Firewalls.
- # Probably an MD5 hash of something.
- FortiGate ^1d6e178f6c2c0be284985465450fe9d4
-
- # Juniper NetScreen
- # There are many different entries for this implementation.
- # The first 20 bytes are suspected to be an SHA1 hash of something
- # It is followed by eight bytes, which we don't include in the pattern.
- # This eight bytes consists of two four-byte values in big endian format,
- # e.g. 0000000900000500, which may indicate the ScreenOS version.
- Netscreen-01 ^299ee8289f40a8973bc78687e2e7226b532c3b76
- Netscreen-02 ^3a15e1f3cf2a63582e3ac82d1c64cbe3b6d779e7
- Netscreen-03 ^47d2b126bfcd83489760e2cf8c5d4d5a03497c15
- Netscreen-04 ^4a4340b543e02b84c88a8b96a8af9ebe77d9accc
- Netscreen-05 ^64405f46f03b7660a23be116a1975058e69e8387
- Netscreen-06 ^699369228741c6d4ca094c93e242c9de19e7b7c6
- Netscreen-07 ^8c0dc6cf62a0ef1b5c6eabd1b67ba69866adf16a
- Netscreen-08 ^92d27a9ecb31d99246986d3453d0c3d57a222a61
- Netscreen-09 ^9b096d9ac3275a7d6fe8b91c583111b09efed1a0
- Netscreen-10 ^bf03746108d746c904f1f3547de24f78479fed12
- Netscreen-11 ^c2e80500f4cc5fbf5daaeed3bb59abaeee56c652
- Netscreen-12 ^c8660a62b03b1b6130bf781608d32a6a8d0fb89f
- Netscreen-13 ^f885da40b1e7a9abd17655ec5bbec0f21f0ed52e
-
- # Avaya
- # Observed on Avaya VSU 100R
- # Not sure if this is common to all Avaya equipment
- avaya ^4485152d18b6bbcc0be8a8469579ddcc
-
- # Stonegate
- # Observed on Stonesoft StoneGate v2.2.1
- StoneGate-01 ^c573b056d7faca36c2fba28374127cbf
- StoneGate-02 ^baeb239037e17787d730eed9d95d48aa
-
- # Other things I've seen but not fully classified yet.
- # If anyone can confirm any of these, please let me know.
- Maybe Cisco IOS ^bdb41038a7ec5e5534dd004d0f91f927
- # Unknown 1 was classified as Cisco VPN Concentrator
- # Unknown 2 was classified as Windows-2000
- Unknown 3 ^edea53a3c15d45cafb11e59ea68db2aa99c1470e0000000400000303
- Unknown 4 ^bedc86dabf0ab7973870b5e6c4b87d3ee824de310000001000000401
- Unknown 5 ^ac5078c25cabb9523979978e76a3d0d2426bc9260000000400000401
- # Unknown 6 was classified as SSH IPSEC Express 4.1.0
- Unknown 7 ^69b761a173cc1471dc4547d2a5e94812
- Unknown 8 ^4c5647362e303a627269636b3a362e302e353732
- Unknown 9 ^3499691eb82f9eaefed378f5503671debd0663b4000000040000023c
- # I've seen Unknown 10 sent from SonicWall Global VPN Client
- Unknown 10 ^975b7816f69789600dda89040576e0db
- # The "Safenet or Watchguard" Vendor ID has also been seen sent from SonicWall
- # Global VPN client. It is normally followed by 80010000, which looks like a
- # version number.
- Safenet or Watchguard ^da8e9378
- Unknown-cisco ^e23ae9f51a46876ff93d89ba725d649d
- Maybe Sidewinder G2 ^8404adf9cda05760b2ca292e4bff537b
- Maybe Sidewinder G2 ^e720cdd49d2ee7b83ce1970a6c69b528
-